Recommended
More Related Content
What's hot
What's hot (20)
Similar to PenTesterが知っている危ないAWS環境の共通点
Similar to PenTesterが知っている危ないAWS環境の共通点 (20)
More from zaki4649
PenTesterが知っている危ないAWS環境の共通点
- 2. Shun Suzaki(洲崎 俊) Twitter:@tigerszk ITイベントの参加・開催や日々の脆弱性検証をライフワークと する「とあるセキュリティエンジニア」 Daiki Ichinose(一ノ瀬 太樹) Twitter:@mahoyaya Perlが好きなウィークデーバグハンター。 土日は家族サービスとコミュニティ活動に勤しんでいる。 Ken Kitahara(北原 憲) 博士（理学）。物理学で博士号を取得してから、2014年4 月から縁も所縁もない情報セキュリティ業界で働き始める。 ネットワーク系のサイバー攻撃技術が専門。
- 3. AWSのセキュリティは？ プラットフォームとしてのセキュリティは堅牢 強固な物理セキュリティ 自由に冗長化やスケーリングが可能 便利なマネージドサービスが用意されている
- 4. じゃあ安心安全？ 仮想通貨盗掘？ ベーシック、AWSで不正アクセス被害 https://www.nikkei.com/article/DGXMZO39233590R21C18A2000000/ AWS営業担当者の設定ミスでGoDaddyの機密情報が公開状態に https://japan.zdnet.com/article/35123924/ ホンダの海外法人が5万人分を超える顧客情報をクラウド上で公開していた https://gigazine.net/news/20180609-honda-app-leaked-personal- information/
- 5. 伝えたいこと 当たり前だが、AWSを使っていたとしても、 セキュリティインシデントは発生しうる プラットフォームが堅牢でも、 最終的にはユーザの使い方次第 システムを運用していく中で、脆弱性が作り こまれる可能性もある 安全に使うには、ユーザ側にてセキュリティを意識 した対策が必要
- 6. 責任共有モデル 低レイヤーはAWSがカバーするが、高レイヤー部分は ユーザ―が対策しなければならない 責任共有モデル – アマゾン ウェブ サービス (AWS)より引用 https://aws.amazon.com/jp/compliance/shared-responsibility-model/
- 7. 安全にAWSを利用するためには 1. オンプレ環境などと同様の対策が必要 実装時や運用で作りこまれてしまう脆弱性などはオンプレなどと同じ EC2などで稼働するアプリケーションのセキュリティは大丈夫？ 2. AWSサービスごとに個別の対策が必要 S3、IAM、セキュリティグループなどの設定は大丈夫？ 3. 必要に応じて便利なマネージドサービスを利用 CloudTrail、AWS WAF、Guard Duty、Amazon Inspector etc…
- 11. AWSにおけるCredentialとは AWSサービスを利用するために必要な認証情報 AWSアカウント（ルートユーザ・IAMユーザ） ID パスワード アクセスキー アクセスキーID シークレットアクセスキー
- 12. AWSアカウント AWS マネジメントコンソールへのサインインに 必要となる AWS Management Console AWS Cloud ルートユーザ IAMユーザ ID パスワード ID パスワード
- 13. アクセスキー AWS API、AWS CLI、AWS SDK、または Windows PowerShell 用 AWS ツールから AWS をプログラム で呼び出す場合に使用する ルートユーザ IAMユーザ アクセスキーID シークレットアクセスキー アクセスキーID シークレットアクセスキー AWS Cloud
- 17. AWSアカウントの場合
- 18. マネジメントコンソール経由での 不正ログイン MFA（多要素認証）が有効でなければ当然狙い所 何らかの方法でユーザID・パスワードを窃取もしくは推測 され、マネジメントコンソールなどから不正ログインされ てしまう ありがちなのは、単純なパスワードの設定や 「パスワードの使い回し」問題 海外のペネトレーションテストでは、ソーシャルエンジニ アリングのテクニック利用したスピアフィッシングなどで、 ユーザID・パスワード情報を取得している
- 19. アクセスキーの場合
- 20. Gitリポジトリ経由での漏洩 Github上にAWSのアクセスキーが公開されたことに より、漏洩するケースは多い 【事例】 • AWSで不正利用され80000ドルの請求が来た話 https://qiita.com/koyama9876/items/add70cba3cccdb7fa995 • 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 https://qiita.com/mochizukikotaro/items/a0e98ff0063a77e7b694 • AWSが不正利用され300万円の請求が届いてから免除までの一部始終 https://qiita.com/AkiyoshiOkano/items/72002409e3be9215ae7e
- 21. AWSもスキャンしてくれてるけど… AWSもGitを検索し、アクセスキーを公開している利用者の リポジトリに通知してくれているが、攻撃者も同じことを やっている そのためAWSからの通知前に悪用される可能性がある 【参考】 • GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！ https://qiita.com/saitotak/items/813ac6c2057ac64d5fef
- 22. 公開されているものだけがターゲット というわけでもない Uber社の情報漏洩では、非公開部分のGitHubよりアクセスキー を奪取されてしまった 標的型攻撃など、別経路で侵入された場合には、内部環境に配 置してあるファイルからCredentialを奪取されてしまう可能性 もありえる 【参考】 • Uber Paid Hackers to Delete Stolen Data on 57 Million People https://www.bloomberg.com/news/articles/2017-11-21/uber- concealed-cyberattack-that-exposed-57-million-people-s-data
- 24. SSRFを利用したCredentialの窃取 SSRF (Server Side Request Forgery)とは？ 【参考】 • SSRF(Server Side Request Forgery)徹底入門 https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html 攻撃者から直接到達できないサーバーに対する攻撃手法の一種 内部NWのサーバー公開サーバー 攻撃者 脆弱性を悪用するリクエストを送信 本来はアクセスできない内部NWサーバ に任意のリクエストを送信し、結果を受 け取れてしまう 内部NWに直接アクセスできない xxx/?URL= http://192.168.1.1 xxx/?URL=http://www.example.com http://192.168.1.1
- 25. AWS APIを利用してCredentialを取得 IAMロールが紐づいた状態のインスタンスにて、AWS APIへ 一時的なCredentialを要求するリクエストを強制させられ、 EC２のIAMロールに紐づいたCredentialを窃取されてしまう。 AWS側のメタデータAPISSRFの脆弱性が存在するEC２攻撃者 脆弱性を悪用するリクエストを送信 AWSのメタデータAPIに対して 一時的なCredentialを勝手に要求 Credentialを含んだ結果が返るCredentialを窃取 【参考】 • インスタンスメタデータとユーザーデータ https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance- metadata.html xxx/?URL=http://169.254.169.254/latest/meta-data/… xxx/?URL=http://www.example.com http://169.254.169.254/latest/meta-data/…
- 27. サーバー内に配置されているCredential サーバー内にアクセスキーが配置されていたり、設定ファイル などが残存しているケースがある AWS CLIなどを利用している場合には、以下の場所か環境変 数に設定されていたりするが他の場所にあることも Linux: /home/USERNAME/.aws/credentials Windows: C:UsersUSERNAME.awscredentials この場合、サーバー内に侵入された場合や、システム内部の ファイルを読み取ることができるような脆弱性（ディレクトリ トラバーサルなど）を利用されることなどによって、取得され てしまう可能性がある
- 30. 権限昇格されてしまう例～その１～ 以下の権限のいずれかが割り当てられている場合には、ポリシーを勝 手に追加することにより、ポリシーの権限を奪取して、権限昇格可能 当然ながら他にもIAMポリシーを作成、追加、更新などできる権限が 割り振られている場合にも、同様の手法で権限昇格が可能 IAMポリシー 用途 iam:AttachUserPolicy ユーザのポリシーを追加 iam:AttachGroupPolicy グループのポリシーを追加 iam:AttachRolePolicy ロールのポリシーを追加 AWS CLIの実行例 //ポリシーの追加 $ awd iam attach-user-policy –-user-name <対象のユーザアカウント> --policy-arn <権限が高いポリシーのARN> $ awd iam attach-group-policy –-group-name <対象のグループ> --policy-arn <権限が高いポリシーのARN> $ awd iam attach-role-policy –-role-name <対象のロール> --policy-arn <権限が高いポリシーのARN>
- 31. 権限昇格されてしまう例～その2～ IAMポリシー 用途 iam:PassRole 存在するロールを資源に割り当て lambda:CreateFunction 新たなLambda関数を作成 lambda:InvokeFunction Lambda関数を実行 AWS CLIの実行例 //Lambda関数の作成 $ aws lambda create-function --function-name <作成する関数名> --runtime python3.6 --role <割り当てるロールのARN> --handler <作成する関数名>.<スクリプト内で定義した関数名> --zip-file <Lambda関数を定義したPythonスクリプトをzip化したファイル> //Lambda関数の実行 $ aws lambda invoke --function-name <作成した関数> <実行結果出力先ファイルパス> 以下の三つの権限が割り当てられており、 権限の高いLambda関数の IAMロールが存在する場合には、任意のロールを割り当てた新たな Lambda関数を作成し、呼び出すことによって、権限昇格が可能となる Lambda以外のマネージドサービスでも同様の手法で権限昇格が可能
- 32. 作成するLambda関数のpythonスクリプトの例 指定したユーザを管理者権限グループに追加するスクリプト もし権限の高いLambda関数のIAMロールが存在する場合などには、 権限を割り振られて実行されてしまう可能性がある import boto3 def lambda_handler(event, context): client = boto3.client(‘iam’) response = client.attach_user_policy( UserName = ‘my_username’, PolicyArn = ‘arn:aws:iam::aws:policy/AdministratorAccess’ ) return response
- 33. AWS環境への攻撃デモ
- 34. 情報収集 権限昇格 バックドアの 設置 AWSサービス の悪用 デモのシナリオ 何らかの経路でAWS Credentialを入手した後、そのCredentialを 元に攻撃者がAWS環境に侵入するというデモです。 攻撃者は侵入後にAWS環境に対して以下の行為を行います。
- 35. Pacu 今回のデモで利用している AWS Exploitation Framework Rhino Security Labsが公開 OSSであり、python3で開発されている AWSのアクセスキーをセットして使用する https://github.com/RhinoSecurityLabs/pacu
- 36. Demo
- 37. 対策
- 38. 対策のアプローチは多く分けて三つ 1. Credentialの漏洩を防止 2. Credentialの悪用を抑制 3. Credentialを悪用されたことを検知
- 39. IAMのベストプラクティスに従おう！ 【参考】 • AWS IAM ベストプラクティスのご紹介 – AWSアカウントの不正利用を防ぐために https://aws.amazon.com/jp/blogs/news/aws-iam-best-practice/ • AWS を安全に使うために（IAM のベストプラクティス） https://dev.classmethod.jp/cloud/sugano-042-iam-best-practices/ IAM のベストプラクティス https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html AWS アカウントのルートユーザー アクセス キーをロックする 悪用を抑制 個々の IAM ユーザーの作成 悪用を抑制 IAM ユーザーへのアクセス許可を割り当てる ためにグループを使用する 悪用を抑制 最小権限を付与する 悪用を抑制 アクセスレベルを使用して、IAM 権限を確認 する 悪用を抑制 ユーザーの強力なパスワードポリシーを設定 漏洩を防止 特権ユーザーに対して MFA を有効化する 悪用を抑制 Amazon EC2 インスタンスで実行するアプ リケーションに対し、ロールを使用する 漏洩を防止 ロールを使用したアクセス許可の委任 悪用を抑制 アクセスキーを共有しない 漏洩を防止 認証情報を定期的にローテーションする 漏洩を防止 不要な認証情報を削除する 漏洩を防止 追加セキュリティに対するポリシー条件を使 用する 悪用を抑制 AWS アカウントのアクティビティの監視 悪用を検知
- 41. 現実的にすべての項目を定期的に確認す るのはかなりしんどい 各社が無料から有料までいろいろなツールを提供 しているので、「ツールでできる部分は」ツール に頼る AWS Trusted Advisor Classmethod insightwatch Netflix Security Monkey
- 43. git-secretsを使おう Credentialを誤って git リポジトリにcommitして しまうことを防いでくれるAWSが公開しているtool awslabs/git-secrets https://github.com/awslabs/git-secrets
- 44. アクセス許可の境界（Permissions Boundary）を利用しよう Permissions PolicyとPermissions Boundaryの２ つのポリシーで、できることできないことの細やか な制限が可能になる機能 主にattach* 系のiamへの攻撃を防ぐことができる 【参考】 • IAM エンティティのアクセス許可の境界 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_pol icies_boundaries.html • [新機能]IAMの委譲権限を制限可能なPermissions Boundaryが登場したので 試してみた https://dev.classmethod.jp/cloud/aws/iam-permissions-boundary/
- 46. 悪用されたことを検知する AWSアカウントのアクティビティは監視が必要 AWS CloudTrailを利用してアカウントアクティビティのログ を取得 Amazon CloudWatchなどでログをモニタリング 平常時のログを自分で分析しておき、異常な動きをし ているものがないかを監視
- 47. Amazon Guard Duty 機械学習を利用してトラフィックログ等から怪 しい通信を検知するマネージドサービス アカウントの不正利用などの監視に有効 【参考】 • Amazon GuardDuty https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/what- is-guardduty.html
- 48. Thank you!